Admin publication page shows the review and the identifier screen - #460

Part of nemarOrg/nemar-cli#1731 (Phase 4 of epic nemarOrg/nemar-cli#1726). Tracking issue: #459.

Summary

The administrator publication page now shows the API's review and the identifier screen and decides on them, and every refusal the API gives is shown in plain words. The page prints the API's own statement and the neutral cure for each reason; it never prints the terminal's sentences (line, command, description.lines, description.next, or a refusal message that names a terminal step), because the terminal's cure carries commands. The API half is nemarOrg/nemar-cli#1779 (it adds the detail fields and the shared words); the decision is this repository's ADR 0027 (the nemar-cli side is in its ADR 0102).

• Review chips and a review panel. Pending, approving and blocked requests show a review chip and a screen chip from the list; opening a request fetches the API's detail and shows the reasons (the API's statement and neutral cure), the identifier screen, and the model's summary and notes only under a label saying the model wrote it, as plain text.
• Approve follows the API's gates. Approve is absent for a reason no override clears, for a blocked request, and when the identifier screen has a direct identifier, no verdict or is still running; a started-publishing run is exempt and offers "Continue approval". A non-pass needs an explicit confirmation and sends an override naming exactly the reasons shown; a screen that needs a person to read it needs a recorded reason of 10 to 500 characters. The typed PUBLISH dialog stays the last step. The page never computes a verdict.
• Every approve and deny names its request (request_id); a stale page is refused by the API and the page re-reads, and a panel whose request is not its row's is drawn as stale with no controls.
• Start review when the API offers one; plain words for every refusal (request_mismatch, approval_in_flight, deny_after_publishing, the review and screen gates, the origin refusal and the rest); a failed or unanswered approve says it may have started and offers a refresh.
• A request blocked by the identifier screen has its own badge, "Identifiers found" (the seventh block reason), which also shows on the depositor's dashboard card.
• A transcribed 22-key table of the words the API words for a terminal (src/lib/publication-review-copy.ts), with a drift test against the nemar-cli file (strict path wired in ci.yml, same dev pairing as the three others, and shared/publication-limits.ts in the sparse checkout for the limits test) and a rule that every key has a consumer; fixtures captured from the real API routes over a real database (each carries how it was captured).

What this needs

The API must deploy before the website. A page promoted ahead of the API gets a detail with no statement, so it withholds the panel, says the page and the API are out of step and offers no Approve; it never falls back to the old empty approve or to the terminal's line. The API half is on nemar-cli dev (epic nemarOrg/nemar-cli#1782), so the strict drift test runs against it in CI, the fixtures were re-captured at the dev head (the only content change is that the list payload now carries dataset_name and withdrawn_at), and staging is merged in (it carries the account copy from #469). The production promotion waits for the API half to reach production first.

Review

All implementation was done by Sonnet agents, each failing test first, with mutation checks. One Opus review of both halves found no Critical defect and one Important (a documentation claim), plus seven Minor findings, all fixed. Fix rounds since then address a Sonnet panel's findings on this pull request.

Test plan

• bun run lint, bun run typecheck, bun run test (strict drift test against the nemar-cli epic checkout), bun run build
• CI green (lint, typecheck, test with the strict drift tests, build) against nemar-cli dev
• the maintainer's browser check of the page on staging, in light and dark themes, in forced colors and at 390 px width:
  • a request that passes the review (Approve offered, typed PUBLISH last)
  • a request with a non-pass (explicit confirmation, override names the reasons shown)
  • a request with a hard reason (no Approve, the reason's words shown)
  • a request whose identifier screen needs a reason (10 to 500 characters recorded)
  • a blocked request (no Approve, "Identifiers found" badge for the screen's block)
  • a run that has started publishing (panel offers "Continue approval")
  • an administrator write from the staging site answers 200, not 403 (the API now checks the Origin of cookie writes on the admin routes)
  • a stale page (another request under the same row, no controls, refresh link)